feat(scope_definition): read action list from service spec by default - #458

Agregué un commit a este branch (df701fbb) para cubrir el caso en que no se
resuelve ninguna acción. Contexto de por qué, con lo que medí probándolo contra una
implementación real:

Sin el default, un caller que dependía de él resuelve a [], y [] en el
for_each de nullplatform_action_specification no significa "dejá lo que había":
significa cero instancias. El plan propone destruir todas las action
specifications del scope, y no hay error porque una lista vacía no lo es.

Medido en implementation-aws antes de que los specs declararan sus acciones:

Plan: 0 to add, 0 to change, 44 to destroy

14  aws_lambda
15  containers
 8  scheduled_tasks
 7  static_files

Un plan que se lee como intencional y deja al scope sin crear/borrar scopes,
deployar, blue/green, rollback ni diagnósticos.

Dónde va el precondition. Lo puse en nullplatform_service_specification y no
en el action_specification, que sería el lugar intuitivo: con for_each vacío ese
recurso no tiene instancias, así que sus preconditions nunca se evalúan. El service
specification existe siempre.

Retrocompatibilidad. Verifiqué los dos caminos contra una implementación:

Así que quien pasa la lista no se ve afectado. Quien dependía del default recibe un
error que dice qué archivo tocar, en lugar de un apply destructivo.

Por otro lado, para que este PR se pueda mergear sin romper a los scopes que hoy
dependían del default, hicimos los specs que faltaban:

• feat(lambda): declare the scope's available actions in its spec scopes-lambda#35 — declara sus 14 acciones
• feat: declare the scope's available actions in its spec scopes-static-files#21 — declara sus 7

nullplatform/scopes ya las trae en feat/scope-definition-available-actions. Con
los cuatro alineados el plan da No changes, o sea que el refactor es transparente.

Sugerencia de orden: los dos PRs de specs primero (son inocuos mientras el módulo
ignore el campo), este último.

Aporto el tofu plan contra una implementación real, que es el último item del test
plan. Corrido en implementation-aws (cuenta aws-services), con los cuatro scopes
apuntando a las ramas correspondientes:

y action_spec_names eliminado del catálogo y del bloque del módulo:

$ tofu plan
No changes. Your infrastructure matches the configuration.

Cero creates, cero updates, cero destroys, para los cuatro scopes — 44 action
specifications en total. El refactor es transparente cuando los specs declaran sus
acciones.

Los dos casos de compatibilidad, probados por separado contra la misma
implementación:

El segundo con este error, que es el comportamiento que buscábamos:

Error: Resource precondition failed
  │ local.static_action_specs is empty set of string

No actions resolved for scope "Static Scope".

Declare `available_actions` in static-files/specs/service-spec.json.tpl,
or pass `action_spec_names` explicitly.

Sobre el ordering: confirmo lo que dice la descripción — ni main ni beta de
scopes tienen available_actions hoy; solo el head de nullplatform/scopes#208. Y
lo mismo pasaba con scopes-lambda y scopes-static-files, que no tenían el campo
en ninguna versión: de ahí los dos PRs de arriba. Sin ellos, esos dos scopes caían al
precondition (antes de este último commit, a 21 destroys).

Dejo la rama de prueba en implementation-aws por si sirve para reproducirlo:
test/available-actions-from-spec.